Summary

Automated update of the libdatadog submodule to the latest HEAD.

Full CI result: ❌ 244 job(s) failed
CI pipeline: https://gitlab.ddbuild.io/DataDog/apm-reliability/dd-trace-php/-/pipelines/146961638

libdatadog Integration Report

libdatadog SHA: 21962c07061b324669aaf9e58cc7cefce7227b7c
Analysis date: 2026-10-23

Overall status

⚠️ Adapted (API changes fixed)

The changes are build-manifest changes, not Rust source changes. They could not
be checked locally because no Rust toolchain is available. CI must confirm them.

Build & test summary

244 jobs failed across the shared, appsec, profiler, package and tracer
sub-pipelines. Every saved trace (45 + 48 of 93 files) shows one of two Cargo
errors. Both happen while Cargo reads the manifests or resolves dependencies,
before any Rust code is compiled:

1. Workspace inheritance failure (48 traces: appsec integration tests,
   helper-rust, sidecar and portable builds):

   error: failed to load manifest for workspace member `/project/sidecar`
   ...
   failed to parse manifest at `/project/libdatadog/libdd-common/Cargo.toml`
   error inheriting `webpki-root-certs` from workspace root manifest's
   `workspace.dependencies.webpki-root-certs`
   `dependency.webpki-root-certs` was not found in `workspace.dependencies`
   

   libdatadog crates are built as members of our workspace, so they inherit
   workspace = true dependencies from our root Cargo.toml. That file must
   mirror libdatadog's [workspace.dependencies]. The new libdatadog added
   these entries:

   • webpki-roots and webpki-root-certs: libdd-common, from ci(profiling): cleanup correctness tests #2702 "bump to
     exclude compromised CAs"
   • httpdate: libdd-ffe CDN fetching, from Bump version to 1.0.0 #2675

   It also raised the rustls-webpki requirement to 0.103.16 (Use valgrind suppressions instead of disabling valgrind #2708).

2. rustls-webpki resolution conflict (45 traces: appsec code coverage,
   test appsec extension, profiling tests):

   error: failed to select a version for `rustls-webpki`.
   ... rustls = "^0.23" (locked to 0.23.37) of package `libdd-common v8.0.0`
   versions that meet the requirements `^0.103.5` (locked to 0.103.13) are: 0.103.13
   previously selected package `rustls-webpki v0.103.16`
     ... which satisfies dependency `rustls-webpki = "^0.103.16"` of package `libdd-common`
   

   libdd-common now requires rustls-webpki ^0.103.16. Our Cargo.lock still
   pinned 0.103.13, and these jobs resolve with only the locked version
   available, so resolution fails.

The remaining job families have no saved traces: Extension Tea Tests, Zend
Abstract Interface Tests, ZAI Shared Tests, PHP language tests,
prof-correctness, Clippy, Cargo test and pecl tests. They all build the same
Cargo workspace first:

• ZAI through zend_abstract_interface/components_rs.cmake
• Tea through make install
• the profiler jobs through cargo
• pecl through the packaged Cargo.toml/Cargo.lock

So they fail for the same reason.

Rust API review of the update

The submodule moved from 634af2c84 to 21962c070 (25 commits). I checked
each breaking (!) commit against our code:

Non-trivial changes made

• Cargo.toml ([workspace.dependencies]): re-synced with
  libdatadog/Cargo.toml as the file's own comment asks:

  • added httpdate = "1.0"
  • added webpki-roots = "1.0.10"
  • added webpki-root-certs = "1.0.10"
  • changed rustls-webpki from ">=0.103.13" to "0.103.16"

  The two [workspace.dependencies] lists are now identical (checked with
  diff).

• Cargo.lock: brought in line with the new requirements. All versions
  and checksums are copied from libdatadog/Cargo.lock:

  • rustls-webpki 0.103.13 → 0.103.16
  • webpki-roots 1.0.6 → 1.0.10
  • webpki-root-certs 1.0.6 → 1.0.10
  • new libdd-trace-model 0.1.0 path package, now referenced from
    libdd-tinybytes, libdd-trace-obfuscation and libdd-trace-utils
  • libdd-common now lists webpki-roots and webpki-root-certs (optional
    deps of the use_webpki_roots feature)
  • libdd-ffe now lists its new optional CDN dependencies: base64 0.22.1,
    fastrand, flate2, futures-util, http-body-util, httpdate,
    hyper, percent-encoding, tokio-util and url

  Each of these crates already had exactly one compatible version in the lock.
  If Cargo still wants to adjust anything it can do so automatically, because
  our builds do not pass --locked. Rerunning cargo update -w locally is
  still a good idea, to normalise the lock file.

No Rust source files needed changes.

Identified libdatadog issues

None identified.

One design friction point, not a bug: every new [workspace.dependencies]
entry in libdatadog breaks dd-trace-php until our mirror in the root
Cargo.toml is updated by hand. Automating that sync, or adding a CI check for
it, would avoid this kind of failure.

Flaky / ignored failures

• [tracer-trigger] macos test_c: failed with job_execution_timeout
  rather than a script failure, and no trace was saved. It most likely depends
  on the same Cargo build and will be fixed with it. If it still times out once
  the build works, treat it as a runner or infrastructure timeout.
• Some affected job families are listed in .gitlab/flaky-jobs.txt and are
  excluded from the merge gate: Extension Tea Tests:*, Zend Abstract Interface Tests:*, test appsec extension:* and PHP language tests:*.
  In this pipeline they failed for the same build reason, not because they are
  flaky.

/cc @bwoebi